Some weeks ago I saw in an AWS public presentation a topic about a RDS service for Oracle databases where you can build your own environments and get full OS access. This was new for me how knows the normal AWS RDS offerings for Oracle databases, where no (or very limited) OS access is possible. And this meant for me as a child of Oracle Cloud Infrastructure: time to play! I spent a lot of time in the last three weeks to take a deep dive. It was, let’s say, a nice experiment. In this blog post I give you an overview what this service for Oracle on AWS is, how you will bring it up and running and what’s behind. Do I find this service useful or useless? Well, let’s take a look…
This is a blog post series about my sightseeing tour inside this AWS service:
- Part 1: Gives you an overview about the setup – HERE WE GO
- Part 2: About connectivity and what you get from AWS
- Part 3: My personal opinion about this service and some words about pricing
Notice: As there are so many steps from the Custom Engine Version until the first connect, not all screenshots are always posted. Files and templates are available on my public github repo here: martinberger-ch/aws-cev-oracle: Templates for AWS Custom Engine Version for Oracle (github.com) – questions: just drop me a message via Twitter or LinkedIn.
What is the AWS Custom Engine Versions (CEV) for Amazon RDS Custom for Oracle
Custom Engine Versions – CEV – is a service where you can build your own Oracle Home versions, some Oracle guys are calling it “Golden Images” of an ORACLE_HOME. This images can be used to ramp up new Oracle databases in the RDS menu context. This means, AWS RDS prepares the host for you, does the Oracle settings and ramps up an Oracle Database with a Listener, ready to use. The process how to build and use a CEV is basically well described. A proper configured underline Virtual Private Cloud VPC is required. In some of my first runs I was able to start an instance, but the RDS service shows a network error message because the on the instance installed AWS systems manager agent was not able to communicate with the AWS ecosystem. Solved by a Security Group rule. Here is simple picture how it works – source: Amazon RDS Custom architecture – Amazon Relational Database Service
- Upload RDBMS,OPatch and patches to a S3 bucket
- Create a Custom Engine Version with these files – a JSON manifest is required
- Create an Oracle RDS instance based on the CEV
There are some other requirements like customer KMS key and a specific IAM role. The underlying host what you get is an EC2 instance. The SSH credentials are stored in AWS Secrets Manager service. An excerpt of the restrictions:
- Oracle Database 12.1 with the January 2021 or later RU/RUR
- Oracle Database 19c with the January 2021 or later RU/RUR
- Support for these instance classes: db.m5.large–db.m5.24xlarge or db.r5.large–db.r5.24xlarge
- Once the instance class is selected, it can’t be changed (you can use a snapshot to build a new RDS instance)
- License model is BYOL only
More information about version limitations and others: Requirements and limitations for Amazon RDS Custom for Oracle – Amazon Relational Database Service
Lets build a Custom Engine Version for Oracle Enterprise Edition RU 19.15
This is part of the RDS section in the menu “custom engine version”. As mentioned above, the required files have to available on the S3 storage and you need an existing KMS key. You can add RUs, RURs, on-off patches etc. to your build. After you have selected the Oracle version 12.1 or 19 – define the storage and the files what you want to include into. Example for the file and storage definition Oracle 19.15 Enterprise Edition with the newest OPatch file, the RU and the OJVM update.
After approximately 2 hrs, the Custom Engine Version is ready to use
RDS – Create an Oracle Database
Before a database can be created, VPC, Endpoints and a policy are a must have. You will find the files for Cloud Formation to create VPC, Endpoints and the IAM role in my public github.com repo mentioned at the beginning of this blog post. Create all this resources first. If you want to create the resources manually, you find the information here: Setting up your environment for Amazon RDS Custom for Oracle – Amazon Relational Database Service.
Select Oracle as engine and Amazon RDS Custom as Database Management Type.
Select the Custom engine version, set a DB instance identifier (this is not the instance name, this comes later) and type in a Master password (this is the password of the database schema admin). If you don’t like admin, just change the Master username.
Configure the DB instance class (cannot be changed afterwards), define Storage type, Allocated storage and Provisioned IOPS.
Select the Virtual private cloud VPC created by Cloud Formation, and choose the existing VPC Security group created by Cloud Formation too.
Select the IAM instance profile created by Cloud Formation, and choose the existing AWS KMS Key what I have already created before.
In Additional configuration, as minimum setting define an Initial database name (this is the instance name). Create Database.
Wait some minutes until the database is listed in status running. It changes from Creating – Backing-Up to Available finally. In case of any errors, you will find the information in the instance tab Logs & Events. Example when the AWS Endpoint for SSM is not configured properly.
EC2 Instance and RDS Overview
A new EC2 instance was started. At this point you can already connect by SSH to the new compute instance, details,like the IP address are listed. How it works? We will see it in blog post part 2. Have you seen the EC2 instance name? This name is auto-generated and later used for the credential handling.
Summary Part 1/3
Creating a CVE image is easy. Just upload the files to S3, write the manifest and build it. When all the prerequisites like VPC, Endpoints,AWS KMS Key, IAM Role and more are ready, then you can start with the RDS database creation job. Fulfill all the requirements first. There are not many instances classes available and once created, it cannot be changed without creating a snapshot of the running database. This results in downtime. In the next blog post we will take look to the connectivity and what’s behind the AWS service. See you!